MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 046

Internet Message Format | 1997-05-06 | 84KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-046
Date: Wed, 20 Jul 1994 14:41:25 +0200 (MET DST)

C.S.M.P. Digest             Wed, 20 Jul 94       Volume 3 : Issue 46

Today's Topics:

        3D Rotational examples - Help wanted
        CASE Tools for Macintosh
        Debugging an applet properly (AppleScript)
        GWorlds vs. Offscreens
        GWorlds: When to lock pixels?
        How do you write TIFFs?
        How to tell Energy Saver to turn the monitor on or off
        Newbie Gworld questions.
        Patching Trap ExitToShell using UniversalProcPtr's
        Porting from Unix to Mac - Summary
        Problems with Metrowerks vs. MPW 68k C calling conventions
        Special #define for Univ. Hdrs?
        Why does THINK C use a jump table?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Malicious Monarch)
Subject: 3D Rotational examples - Help wanted
Date: Tue,  5 Jul 94 14:39:38 MDT
Organization: The Nile BBS

     I'm looking for some examples in creating simple three dimensional objects
in C.  I've just started reading Michael Chen's article in issue 14 of develop,
but I imagine there are some references to explain the use of the Graf3D library
and perhaps even some more simplistic code to give a basic understanding of
creating and drawing three dimensional objects.

     Please understand that I'm not concerned with a user interface at this
point, just simple rendering code (ie making a cube and rotating it to give the
illusion that it is a three dimensional object).  If someone could point toward
some source code, or any literature (books, magazines, etc.) I would really
really appreciate it.  Thanks...


-Eric A. Drumbor-

     Opinions posted are of the user, not the administration.

+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: Tue, 5 Jul 94 17:58:41 GMT
Organization: University of Pittsburgh

In Article <[e-mail]>, [e-mail] (Malicious
Monarch) wrote:

>     Please understand that I'm not concerned with a user interface at this
>point, just simple rendering code (ie making a cube and rotating it to give the
>illusion that it is a three dimensional object).  If someone could point toward
>some source code, or any literature (books, magazines, etc.) I would really
>really appreciate it.  Thanks...

  There is some code called "wireframeorama" (or something like that)
    that's at both sumex and umich.  A couple of good books are:

   _Computer_Graphics_ 2nd ed by Hearn & Baker ISBN 0-13-161530-0

   _3D_Computer_Graphics_ 2nd ed by Alan Watt  ISBN 0-201-63186-5

  One general procedure is to imagine your "object" in 3D space
    (say with x,y,z co-ords centered around 0,0,0 to start),
    then imagine an "observer" in the same space (say at x,y,z=0,0,100)
    and a perpandicular plane between them (say at z= 70).

  Rotate, translate or do whatever to the object (working in cartesian it's
    pretty easy - it's also handy to add a fourth parameter as a scaler
    for xy&z - say t) then imagine vectors from the observer to each
    point of your object (say the vertices of the cube).  The points
    where your vectors intersect the plane are the points you want
    to map to your graphics port.  Then just connect the dots in your
    graphics port.  With wire frame, you don't have to worry 'bout
    which point is closer to the observer.

  Hmmm... not the best explanation, but I'm kind of new to this too.
    Check out those books (or anything around T385 in your library),
    it's a lot easier than it seems at first.  Luck,

                                            -- nick





   _/   _/  _/  _/_/_/   _/   _/  Sea Shells to C shells,  Waikiki to
  _/_/ _/  _/  _/   _/  _/_/_/     the Internet, a wave, is a wave...
 _/ _/_/  _/  _/       _/ _/
_/   _/  _/   _/_/_/  _/   _/  CompSrv: 71232,766 I-Net: [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Carl B. Constantine)
Date: Wed, 06 Jul 1994 07:40:20 -0700
Organization: Ministry of Environment, Lands & Parks

In article <[e-mail]>, [e-mail] ( nick.c ) wrote:

> In Article <[e-mail]>, [e-mail] (Malicious
> Monarch) wrote:
>
> >     Please understand that I'm not concerned with a user interface at this
> >point, just simple rendering code (ie making a cube and rotating it to
give the
> >illusion that it is a three dimensional object).  If someone could
point toward
> >some source code, or any literature (books, magazines, etc.) I would really
> >really appreciate it.  Thanks...
>
>   There is some code called "wireframeorama" (or something like that)
>     that's at both sumex and umich.  A couple of good books are:
>

[ snip ]

I have a good file (better than wireframeorama) that uses the Graph3D
library and rotates and scales (I think) an object in 3D space.

e-mail me if you're interested.  I may post it (it's small)

--
========================================================================
Carl B. Constantine                  B.C. Environment, Lands & Parks
End-User Support Analyst             [e-mail]
 PGP Key available if you finger: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Wed, 6 Jul 1994 15:32:47 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

On devtools.symantec.com there's a file called 3DGraphics (something like
that) which is a port to C from the old Lisa Pascal "Boxes" and
"BoxSpheres" programs sources.  Uses the Graf3D lib.

There are some rotaters on alt.sources.mac's home site.  One is a color
Graf3D thing written by [e-mail], as a learning tool for Graf3D.
One is a revival of some old code called "ROT-PSIG" in the snippets as
rotpsig2.  Lots of comments in this file, on the whole rotation thing
(non-Graf3D).

I've got 3 Pascal source (the C port doesn't run yet) for
rotating/animating 3D spheres and geometric shapes.  One came from AOL
and one from the CUMUG files.  Icosahedron6 is the latter.  Both use
"light sources" and thus shading.

-Ken-

---------------------------

>From [e-mail] (Steve &)
Subject: CASE Tools for Macintosh
Date: 29 Jun 1994 20:16:59 GMT
Organization: Department of Mathematics and Statistics, Simon Fraser University

I've been looking into CASE tools for use with the Mac, and from a run
through several issues of the Journal of Object Oriented Programming (JOOP)
and Object Magazine (OM); I've found four.

This is a pretty crappy summary of what I found, but I hope to add to it.

If you know of or sell any others, please let me know and I'll post a better
summary.  I'd quite like to hear of any experiences you have had with
any Mac CASE tool, or of any review articles in MacUser or Mac World.

Cheers!
______________________________________________________________________________
Vendor    Berard Software     Excel software  Iconix Software   Object Inter-
          Engineering Inc                     Engineering       national, Inc

Tool      The Berard Object   MacAnalyist,    ObjectModeler     ObjecTool
          and Class Specifier MacDesigner

Method    Berard, &c          ?               Rumb, &c          ?

platform  Mac "this summer",  Mac             Mac, others soon  all(!)
          Win, OS/2

advert    p34 OM Sep 93       p45 OM Sep 93   p8 OM Dec 93      p6 OM Sept 93

review    p85 OM Sep 93                       p98 OM Nov 92     p94 JOOP v6#3

price $US 595                                                   995

code gen? Y                                                     Y

+++++++++++++++++++++++++++

>From [e-mail] (Naresh Bhatia)
Date: Sat, 2 Jul 1994 19:31:53 GMT
Organization: MultiQuest Corporation

Steve & ([e-mail]) wrote:
: I've been looking into CASE tools for use with the Mac, and from a run
: through several issues of the Journal of Object Oriented Programming (JOOP)
: and Object Magazine (OM); I've found four.

: If you know of or sell any others, please let me know and I'll post a better
: summary.

MultiQuest Corporation offers an object-oriented tool, called S-CASE,
that implements the Booch method. The Mac version is $249. I am attaching
a short summary for your information.

Naresh Bhatia
MultiQuest Corporation


S-CASE  is  a  multi-user  software  engineering  tool that supports the
Booch method  of object-oriented  design. The  product allows developers
to create models of their systems using graphical tools that  understand
the  semantics  of  the  Booch  methodology.  C++  code can be generated
automatically from  these models.  S-CASE is  one of  the first tools of
its kind  to operate  on heterogeneous  networks of  PC, Macintosh,  and
UNIX workstations.

S-CASE allows developers to experiment with many design approaches. High
level designs  can be  created quickly  and later  refined by filling in
details about class methods and attributes.

The tool's C++ code generation  encourages engineers to spend more  time
in the critical analysis and  design phases and spend less  time writing
code. C++  headers and  method stubs  are generated  directly from class
diagrams. The engineer simply fills in the body of the methods.

S-CASE lets you  conduct on-line interactive  design reviews. Ideas  are
quickly conveyed to colleagues and customers through concise full  color
diagrams. Presentation  quality output  provides hard  copy handouts and
documentation.

S-CASE stores data in a platform independent format allowing  multi-user
access across different platforms.

Available immediately, S-CASE lists at:
           $249  MS Windows and Macintosh
           $995  Sun SPARC and HP 9000
           (floating and site licenses also available)

Demos can be downloaded via  anonymous ftp at ftp.netcom.com. The  demos
are under /pub/showcase.

The  Microsoft  Windows  demo  is  also  available  on CompuServe in the
CASEFORUM. The demo is named  "showcase.zip" and is located in  the CASE
library.

For further information please contact:

              ------------------------------------------
                        MultiQuest Corporation
                  1699 East Woodfield Road, Suite A-1
                       Schaumburg, IL 60173, USA

                          Tel: [phone]
                          Fax: [phone]
                   Email: [e-mail]
              ------------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (Lars Farm)
Date: Mon, 04 Jul 1994 08:38:06 +0100
Organization: Mid Sweden University

In article <[e-mail]>, [e-mail] (Naresh
Bhatia) wrote:

> Steve & ([e-mail]) wrote:
> : I've been looking into CASE tools for use with the Mac, and from a run
> : through several issues of the Journal of Object Oriented Programming (JOOP)
> : and Object Magazine (OM); I've found four.
>
> : If you know of or sell any others, please let me know and I'll post a better
> : summary.
>
> MultiQuest Corporation offers an object-oriented tool, called S-CASE,
> that implements the Booch method.

S-CASE? So they changed the name? I know it as Showcase and it is nice. Has
editors for (new) Booch class diagrams and (new) Booch object interaction
diagrams. Quite useful and usable! (even though the "crossplatform" nature
shines through in some details.)

Lars

--
[e-mail]

---------------------------

>From [e-mail] (Boris Levitin)
Subject: Debugging an applet properly (AppleScript)
Date: Tue, 5 Jul 1994 11:41:58 GMT
Organization: The World @ Software Tool & Die

I'm writing a large AppleScript applet, and have two problems:

1. I need to have a reliable way to refer to the applet's own
parent folder, because that's where I store some configuration
files the applet uses (I don't want to hardcode the path).
"path to me" returns the path to the applet only when it's running
as an applet. When it's run from inside Script Editor, "me" is
interpreted to be Script Editor -- not the desirable effect. I'm
tired of having to hardcode in a path every time I need to debug
the applet; is there any way to say, path to this very script file?

2. I have a large idle handler in my applet, and there doesn't seem
to be a way to have Script Editor send an idle message to the applet
when it's being debugged in it. Consequently, I have to comment out
the on idle and end idle statements every time I debug. It's annoying,
like item 1.

I would appreciate any suggestions.


--
Boris Levitin                                  WGBH Public Broadcasting, Boston
                                   [e-mail] * [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 6 Jul 1994 16:22:59 GMT
Organization: Apple Computer

Boris Levitin, [e-mail] writes:
> "path to me" returns the path to the applet only when it's running
> as an applet. When it's run from inside Script Editor, "me" is
> interpreted to be Script Editor -- not the desirable effect. I'm
> tired of having to hardcode in a path every time I need to debug
> the applet; is there any way to say, path to this very script file?

Nope. AppleScript has no idea where the script it's executing is stored.

> 2. I have a large idle handler in my applet, and there doesn't seem
> to be a way to have Script Editor send an idle message to the applet
> when it's being debugged in it.

Not unless you explicitly say "idle" in your main body or 'on run' handler.
The runtime environment of an applet is different than one being run by the
editor, so it wouldn't really make sense for a script to be sent idle events
while in the editor.

These things have both annoyed me too. But I couldn't think of a clean
solution that didn't involve major reworking of the way scripts are edited in
AS 1.X.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 06 Jul 1994 12:19:45 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Boris Levitin)
wrote:

> I'm writing a large AppleScript applet, and have two problems:
>
> 1. I need to have a reliable way to refer to the applet's own
> parent folder, because that's where I store some configuration
> files the applet uses (I don't want to hardcode the path).
> "path to me" returns the path to the applet only when it's running
> as an applet. When it's run from inside Script Editor, "me" is
> interpreted to be Script Editor -- not the desirable effect. I'm
> tired of having to hardcode in a path every time I need to debug
> the applet; is there any way to say, path to this very script file?
>
> 2. I have a large idle handler in my applet, and there doesn't seem
> to be a way to have Script Editor send an idle message to the applet
> when it's being debugged in it. Consequently, I have to comment out
> the on idle and end idle statements every time I debug. It's annoying,
> like item 1.

You might give Script Wizard a try (there is a demo [can't save scripts]
version available at

  ftp://gaea.kgs.ukans.edu:applescript/demos/ScriptWiz.Demo.sit.hqx

(there's a press release "beside" the demo file in the same directory).

Note that I say "try":  I don't know whether "they" addressed the idle
question or not.  Script Wizard is one of two OSA script editors recently
announced, to fill the high-end of the editing services spectrum (it is
said that Apple intentionally left that end open for third parties).  The
other one isn't quite out yet.

Meanwhile...for debugging, I'd hard-code a path.  When the path to me
returns a path to the Script Editor, have the run handler pass your action
code the hard-coded path...otherwise have it pass the result from path to
me.  Just remember not to give your script editor a clever name which
breaks your test.
   if (path to me) contains "Script Editor" then ...

--John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   No hablo Intel.
   [e-mail]

---------------------------

>From [e-mail] (P. Hoyer)
Subject: GWorlds vs. Offscreens
Date: 18 Jun 1994 02:03:40 +0300
Organization: University of Helsinki

Once again, Hello netters!

Since it's almost 2 A.M. here in Finland and I'm waiting for the Spain
vs. South-Korea soccer game to begin, I thought I'd ask a question that
has long been on my mind.

I've been using regular old-style offscreen grafports (both 8-bit and
b&w) for a few years now, and since I have reusable code to create these
offscreens, I've never taken the trouble to really find out how GWorlds
differ from these offscreens. Since I don't own the latest in Inside
Macs, I can't look it up there.

So, what are the advantages of GWorlds? Is there really any reason to
switch from offscreen grafports? I guess the main argument would be
"they're easier to use" but since I already have working routines
offscreens aren't a problem for me.

If this message is a bit unclear, it's only 'cause it's 02:04 in the
morning and I'm tired as hell... :)

-P. Hoyer <[e-mail]>

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Sat, 18 Jun 1994 13:08:48 GMT
Organization: The Information Workshop

In article <2tta4c$[e-mail]> P. Hoyer, [e-mail]
writes:

> So, what are the advantages of GWorlds? Is there really any reason to
> switch from offscreen grafports? I guess the main argument would be
> "they're easier to use" but since I already have working routines
> offscreens aren't a problem for me.

Well, as they say, "if it ain't broke, don't fix it".  If you are having
good luck, then by all means don't change unless you need to.


The advantages of GWorlds that come to mind include...

* Apple is responsible for the source code, not me. :)
  ( this is my favorite advantage :)

* One simple call handles the creation of an entire GWorld,
  which includes the pixmap, grafport, and graphic device,
  and color table.

* GWorlds handle aligning themselves with destination screen.

* Passing 0 for the bit depth causes GWorlds to pick up the
  attributes of the screen containing the majority of the
  passed global rectangle, automatically.

* After you create the GWorld, there are calls to conveniently
  obtain the pixmapHandle so you can lock it

* A single call (UpdateGWorld) will do whatever is necessary to
  ensure that the GWorld is totally optimized for fastest transfer
  to the screen, including aligning its pixels with the screen's,
  and making sure the source and destination color tables match.

* Pixels can be purged and restored, and also cached on a NuBus card
  based graphics accelerator transparently.

There may be more advantages.


The benefit of GWorlds handling and hiding all of the concerns
of graphic devices has allowed me to have the confidence that my
software will work on any screen out there, and I didn't have to
learn a single thing about the internals of graphic devices!

But as I say, the best part is that Apple maintains the code.

I am totally certain that there is at least one thing in their
code that I would have never figured out.  :)

But also, if your's works fine, don't change it unless you must.

Spend your time, instead, on your struggle to get your palettes and
color tables working properly.  :)

- ---------

When it comes to Palettes and Color Tables, there IS a big need
for some help in this area.  There are almost no examples, and
Forest Tanaka mentioned once that there won't be much new
in this area, if anything, in Quickdraw/GX.

It took me days and days of trying every combination and permutation
to zero in on what I am supposed to do, so that I am a courteous guy
with respect to other applications and their color needs.  These
"interapplication issues" are not documented, nor is there example
source code that has everything working together, and I have
scoured the earth in search of some.

BTW, in one's update event handler, you can include a call to
UpdateGWorld.  If everything is fine, then it returns immediately.

If, however, the user moved into the background, and now the other
app's color table is in control, or the user changed the bit depth,
then UpdateGWorld will either handle the situation for you ( and
there will be a slight delay ) or you will get the signal that
you must redraw your graphics into the GWorld because the user
increased the bit depth ( since the color detail was lost when the
user decreased the bit depth ).

Ensuring the color tables match has a BIG impact on performance. The
difference is easily perceptible.

If you put a call to UpdateGWorld whenever the window is moved or
resized, then you can rest assured your pixels will be automatically
realigned, if necessary, for optimum performance as well.


Hope this helps.

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (P. Hoyer)
Date: 18 Jun 1994 22:09:43 +0300
Organization: University of Helsinki

>
> But as I say, the best part is that Apple maintains the code.
>

So what you essentially mean is that GWorlds are less likely to break
when Apple decides to move stuff around and change stuff? This seems
like a good reason to switch sooner or later...

>
> But also, if your's works fine, don't change it unless you must.
>
> Spend your time, instead, on your struggle to get your palettes and
> color tables working properly.  :)

Well, since I've mostly written simple games which use the System
palette, I haven't had to worry about colors really. Now, I'm making a
little more serious game that will probably need a custom
palette...hmmm, I think I ought to get some example code on GWorlds.
Would anybody happen to have any good sample code?

I read about the Palette Manager in IM V (it's the latest I've got). Has
it evolved much since the days of the MacII? ;)

-P. Hoyer <[e-mail]>

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Sat, 18 Jun 1994 23:24:18 GMT
Organization: The Information Workshop

In article <2tvgpn$[e-mail]> P. Hoyer, [e-mail]
writes:

> I read about the Palette Manager in IM V (it's the latest I've got).
> Has it evolved much since the days of the MacII? ;)

Not much. I think there are were some updating options added.


As for examples, there are tons of them.  You will want to download files
you find in the development source code areas of umich and sumex, in
addition to ftp.apple.com.

DTS.lib is also an excellent reference.

Also, there are lots of examples all over the Developer CD, and a must
have article is "Drawing in GWorlds for Speed and Versatility" from the
May '92 issue of develop (includes source code).

Also, I have learned a lot from GMonde, and ResetColors, both by Forest
Tanaka.

Hope this helps.

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 21 Jun 94 14:16:17 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, Mark Hanrek <[e-mail]> writes:
>
> The advantages of GWorlds that come to mind include...
(lots of good ones omitted).

It is true. GWorlds take care of 90% of your needs. As one who started messing
about with Color QuickDraw on one of the first Mac II's to hit New Zealand
(back in 1987), it is *much* less fiddly to use GWorlds than to try to create
your own GDevices.

However, there are a few things you can't do with GWorlds. For a start, you
can't create a GWorld that does its drawing into a pre-existing pixmap.

In deference to my current enthusiasms, I should point out that the
offscreen support in QuickDraw GX doesn't suffer from this problem. :-)

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From Alex Kac <[e-mail]>
Date: Fri, 1 Jul 94 23:33:06 -0500
Organization: Delphi ([e-mail] email, 800-695-4005 voice)

See if you can get the MacTech magazine from (I think...), April and May which
have a complete tutorial on using GWorlds...

---------------------------

>From Gordon Graber <[e-mail]>
Subject: GWorlds: When to lock pixels?
Date: 6 Jul 1994 13:14:55 GMT
Organization: Drake University

How Do All,
Several questions about locking a GWorlds pixels:
1.  Must you lock the pixels to the GWorld if you have specified
NoPurgePixels for the GWorld?
2.  If drawing and copyBitsing between several GWorlds in a loop, can one
lock the pixels for each GWorld before the start of the loop and then
unlock them after the loop is done executing?
3.  If you knew you were going to access several GWorlds often in a
program, why not lock the pixels at the outset and unlock them when the
program ends?
3a.  If this results in some kind of memory fragmentation, is there a way
of optimizing this? ( like moveHi(); Lock(); ?)
4.  Why do you not have to lock the pixels to the main screen, or do you?
5.  Are there any conditions, possible exceptions above, under which one
does not need to lock the pixels?

Thanks for any help,
  Gordon Graber:  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Christian Taylor)
Date: 6 Jul 1994 11:31:40 -0300
Organization: Nova Scotia Technology Network

As far as I know, you should always lock the pixels when you're drawing.
Most drawing commands are safe and don't move memory, but things like
PlotIcon do, and you'll lock up the computer if you leave the pixels
unlocked.  When I create a GWrold, I usually lock the pixels right after
and the unlock them in my de-init routine.

Christian


+---------------------+----------------------------------+
|  Christian Taylor   | Internet: [e-mail] |
|The Party Palace BBS | CIS     : 71442,1161             |
|   [phone]    | AOL     : Chris1020              |
+---------------------+----------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 6 Jul 94 14:35:09 GMT
Organization: PowerTools, Austin, Texas

In article <2veaof$[e-mail]> [e-mail] (Gordon Graber) writes:

>Several questions about locking a GWorlds pixels:

>1.  Must you lock the pixels to the GWorld if you have specified
>NoPurgePixels for the GWorld?

Yes. NoPurgePixels simply keeps the pixels in memory. It doesn't keep
them from moving. Incidentally, pixels are non-purgeable by default --
unless you've made them purgeable on creation or later, they'll stay
around.

>2.  If drawing and copyBitsing between several GWorlds in a loop, can one
>lock the pixels for each GWorld before the start of the loop and then
>unlock them after the loop is done executing?

Yes, unless memory is really tight and/or there is a lot of allocation
and deallocation within the loop in question.

>3.  If you knew you were going to access several GWorlds often in a
>program, why not lock the pixels at the outset and unlock them when the
>program ends?

Unless memory is really tight and/or (et cetera), this is a good thing
to do. To the extent that you can do so, allocate all the memory you'll
need at startup, and lock it down.

>3a.  If this results in some kind of memory fragmentation, is there a way
>of optimizing this? ( like moveHi(); Lock(); ?)

I don't know whether this is "guaranteed", but in my experience
LockPixels() already does a MoveHi().

>4.  Why do you not have to lock the pixels to the main screen, or do you?

Because they can't move. Even if you physically move your monitor, the
graphics memory for that monitor stays in the same place:-)

>5.  Are there any conditions, possible exceptions above, under which one
>does not need to lock the pixels?

You don't need to lock them if 1) you are operating on them entirely
from within your own code, without calling ToolBox routines, and 2)
if you don't do any memory allocation/deallocation from within that
code. They will stay where they are unless there's a reason for them
to move.
                    --Al Evans--
--
Al Evans            |   Graphic Elements: A new standard for
                |   high-performance interactive Macintosh graphics.
[e-mail]  |   Available from mac.archive.umich.edu
                |   /mac/misc/demo/graphicelementsdemo.sit.hqx

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Wed, 6 Jul 1994 15:33:56 GMT
Organization: The Information Workshop

In article <[e-mail]> Al Evans,
[e-mail] writes:

>>4. Why do you not have to lock the pixels to the main screen ?
>
> Because they can't move. Even if you physically move your monitor, the
> graphics memory for that monitor stays in the same place :-)
>

Al,

You crack me up! :) :) :)

Mark

---------------------------

>From [e-mail] (tfullert)
Subject: How do you write TIFFs?
Date: 6 Jul 1994 17:32:44 GMT
Organization: The Ohio State University

Greetings:

I am developing an application where I must export graphics as TIFFs.
Does any free source exist for this exist?  Where might I find it?

Thanks.

Tim

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Thu, 7 Jul 1994 01:47:33 GMT
Organization: The Information Workshop

Subject: How do you write TIFFs?
From: tfullert, [e-mail]
Date: 6 Jul 1994 17:32:44 GMT
In article <2veprs$[e-mail]> tfullert,
[e-mail] writes:

> Greetings:
>
> I am developing an application where I must export graphics as TIFFs.
> Does any free source exist for this exist?  Where might I find it?
>
> Thanks.
>
> Tim


Tim,

I suggest you use Archie, because it will easily pull up trillions of
places where TIFF source code can be found.  This is usually a package by
Sam Leffler for unix systems.

Also, the URT (Utah Raster Toolkit) has TIFF writing code. ( University
of Utah :).

A package called MegaTIFF can be found on AppleLink ( I think that is Sam
Leffler's package kinda ported to MPW ).

You will also want to look on CompuServe, which is where the "Aldus
Developer Desk" lives, and example source code can be found there, in
addition to the test suite of TIFF pictures.

You will also want to definitely have your own copy of the TIFF 6.0
Specification.  Get it and print it from the PostScript formatted
version.  It is a beautiful and well-written document that will clarify
many things for you. ( wierd, huh? :)

This document can be found on umich, and possibly sumex.

The other things I can think of only decode TIFF, and I've mentioned all
the good stuff anyway.


Hope this helps.

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (Bob Carpenter)
Date: Wed, 06 Jul 1994 20:34:28 -0800
Organization: Northwest Nexus Inc.

In article <2veprs$[e-mail]>,
[e-mail] (tfullert) wrote:

> Greetings:
>
> I am developing an application where I must export graphics as TIFFs.
> Does any free source exist for this exist?  Where might I find it?
>
  At SGI's anonymous ftp sit (ftp.sgi.com) in directory: graphics/tiff
  you'll find much information and source code for working with TIFFs.
  You'll also find the latest version of the TIFF specification (6).

  You may also want to subscribe to the tiff mailing list by sending
  the word subscribe in the body of a message to:

    [e-mail]

--
--BobC

---------------------------

>From [e-mail] (Tim Smith)
Subject: How to tell Energy Saver to turn the monitor on or off
Date: 4 Jul 1994 13:35:09 GMT
Organization: University of Washington School of Law, Class of '95

A few months ago, I spent a while disassembling Apple's Energy Saver
control panel to figure out how it worked.  I needed to know this
because I wanted to make it work for me under A/UX.  That effort was
a success, allowing me to create an extension, Energy Beaver, that
loads before Energy Saver under A/UX, and diddles a few things so
that Energy Saver will be happy.  (Energy Beaver, plus source code,
is available on ftp.u.washington.edu, in public/tzs, if anyone wants
it).

A couple of weeks ago, someone asked me via email how one interfaces
to Energy Saver.  They wanted to add Energy Saver support to a screen
saver they were working on.  It occured to me that this might be of
interest to others, so I decided to post a copy of my response here.
That is appended at the end of this post.

Apple's Energy Saver actually consists of three components.  A
driver that patches into the video driver and actually does the
hardware manipulation (this driver is contained in an INIT
resource, so you won't find a DRVR in the Energy Saver file),
an INIT that is basically a screen saver that calls the driver
when it is time to blank the screen or unblank it, and a CDEV
that provides the interface.  When you turn Energy Saver off
from the CDEV, all you are really doing is telling the screen
saver INIT to turn off.  The driver is still active, and can
be called from other software to turn the monitor off and on.

- --------- copy of letter follows --------

Hello;

    I've looked at the Energy Saver disassembly, and done a little
experimenting.  Here's the information you need, I think.

1. Determining if Energy Saver supports a particular video card.

Issue a status call to the driver, with csCode=11, and csParam containing
a pointer to a data area of 6 bytes.  I don't think it matters what you
place in this data area, but Apple places zeros there, so I'd do that
too.  If this control call does not return an error, then the Energy
Saver driver is installed for that monitor.

2. To enter Energy Saving mode.

Step through the graphics device list.  For each device, determine if
Energy Saver is installed for that device using that above test.  For
each that it is, do a control call with csCode=11 (that's decimal 11,
not hex 11), and csParam containing a pointer to a data area of six
bytes.  In that six bytes, place the following: 0x01, 0x01, 'H', 'A',
'L', ' '.

3. To exit Energy Saving mode.

This is similar to entering Energy Saving mode, except that those first
two bytes of the six byte data area should be 0x00 and 0x00 instead of
0x01 and 0x01.

After you've turned everything on, for each monitor do a status call
with csCode=11, and csParam containing a pointer to six bytes of data.
Fill out that data area with 0x00, 0x00, 'H', 'A', 'L', ' ' before
doing the call.  After the status call, check byte 1 of the six byte
data area (numbered from 0).  If that byte ANDed with 0x80 is non-zero,
then do the following:

        short temp = (*g)->gdMode & 0xffff;
        (*g)->gdMode = 0;
        SetDepth(g,temp,0,0);

where g is a handle to the GDevice record for the monitor.

After you've set the depth on all the monitors that need it, call
DrawMenuBar.

4. Some observations.

I don't think it matters whether or not the 'HAL ' stuff is placed in
the six byte data area in the control and status calls.  I didn't
notice anything that checked for this in the driver that handles these
calls when I disassembled them.

Energy Saving mode seems to scramble some of the VRAM.  When it comes
out of Energy Saving mode, there are random colored pixels scattered
around.  That business with SetDepth seems to be to get everyone to
update the screen.  If you are doing this from a screen saver, presumably
you will already be making everyone redraw, so you probably don't need
this.

The status call seems to modify the first two bytes of the six byte data
area pointed to be csParam.  I do not know what the significance of byte 1
is, other than it seems to contain that flag that tells if the monitor
needs to have the screen redrawn to clean up the garbage.  Byte 0 seems
to get written with 0x00 if the monitor is not in Energy Saving mode,
and 0xFF if it is.  Apple's software does not seem to make use of this,
so it is not clear that it is safe to rely on it.

5. Sample code.

Here is a simple program fragment that enters Energy Saving mode, waits for
a mouse click, and then leaves Energy Saving mode.


    CntrlParam    c;
    GDHandle    g;
    OSErr        e;
    short        res[3];        // the six byte data area

    //
    // We'll just do the first screen
    //
    g = GetDeviceList();

    c.ioCRefNum = (*g)->gdRefNum;
    c.csCode = 11;
    res[0] = 0; res[1] = 0; res[2] = 0;
    *(short **)(&c.csParam[0]) = &res[0];
    c.ioCompletion = 0;
    e = PBStatus( (ParmBlkPtr)&c, 0 );
    if ( e )
    {
        cout << "Energy Saver not supported!" << endl;
        return;
    }

    //
    // Turn monitor off
    //
    c.ioCRefNum = (*g)->gdRefNum;
    c.csCode = 11;
    res[0] = 0x0101; res[1] = 'HA'; res[2] = 'L ';
    *(short **)(&c.csParam[0]) = &res[0];
    c.ioCompletion = 0;
    e = PBControl( (ParmBlkPtr)&c, 0 );

    //
    // Pause until the mouse is clicked
    //
    while ( ! Button() )
        ;
    while ( Button() )
        ;

    //
    // Turn monitor back on
    //
    c.ioCRefNum = (*g)->gdRefNum;
    c.csCode = 11;
    res[0] = 0x0000; res[1] = 'HA'; res[2] = 'L ';
    *(short **)(&c.csParam[0]) = &res[0];
    c.ioCompletion = 0;
    e = PBControl( (ParmBlkPtr)&c, 0 );

    //
    // See if we need to set the depth to clean up the garbage
    //
    c.ioCRefNum = (*g)->gdRefNum;
    c.csCode = 11;
    res[0] = 0; res[1] = 'HA'; res[2] = 'L ';
    *(short **)(&c.csParam[0]) = &res[0];
    c.ioCompletion = 0;
    e = PBStatus( (ParmBlkPtr)&c, 0 );

    if ( res[0] & 0x0080 )
    {
        short temp = (*g)->gdMode & 0xffff;

        (*g)->gdMode = 0;
        SetDepth(g,temp, 0, 0 );
    }


---------------------------

>From [e-mail] (Alex Tang)
Subject: Newbie Gworld questions.
Date: 3 Jul 1994 14:11:22 GMT
Organization: University of Michigan

Hi folks.  I've got some pretty newbie'ish questions about Gworlds...

First, i haven't been able to find a good explaination about what they're
used for.  From the various bits of info that I've picked up, they
comprise of a lot of different graphics devices and tools (i.e. offscreen
drawing).  Is that right?  Is the main purpose for them so that offscreen
drawing is easier?

The main reason i'm asking is that I'm trying to write a small,
rudamentary graphics app.  It's something to teach me how to do
mac programming.  Basically, it's supposed be able to open some windows,
do some drawing into the wndows, and save the file as a PICT.  I've hit a
minor roadblock trying to figure out how where to draw the stuff and be
able to do updates on it.  At first, I thought I could draw directly to
the window, but that didn't work.  I'm trying to figure out if i need to
use gworlds for this (and i guess i should learn about them anyway).

Well, Thanx for any insight that is provided.

...alex...

--
    Alex Tang      |     UM-SNRE     |       UM-ITD/US Consultant II
[e-mail] |     Student     | http://www.snre.umich.edu/~altitude
  PGP via finger.  |  Systems Admin  | "Life's a game.
This space for rent| Comp.Consut III |  play for fun, and play with Honor."

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 4 Jul 1994 01:06:54 GMT
Organization: cellular

[e-mail] (Alex Tang) writes:

>Is the main purpose for (GWorlds) so that offscreen drawing is easier?
>The main reason i'm asking is that I'm trying to write a small,
>rudamentary graphics app. ...it's supposed be able to open some
>windows, do some drawing into the wndows, and save the file as a PICT.

The question should be then, whether this drawing is going to require
you to use CopyBits. CopyBits is the routine used to shove bit maps and
pixel maps around in memory, on-screen and off-screen and in between
the two. You need it only if you need to do some image processing which
occurs as a side-effect of calls to CopyBits (colorizing bitmaps,
dithering, blending pixel maps, etc.) *or* you're trying to do some
updating which needs to be smooth or animated.

If the answer to this sort of question is "no", then don't bother with
GWorlds. Stick with Pictures. They're easier to deal with and they can
be translated almost directly into PICT files (such files are 512 bytes
of 0 followed by the contents of a PicHandle).

>I've hit a minor roadblock trying to figure out how where to draw the
>stuff and be able to do updates on it. At first, I thought I could draw
>directly to the window, but that didn't work...

Yes, and I understand the problem. Pictures will allow you to get around
this quite nicely, and in general in less memory than GWorlds, too.

Happy reading!
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

 "...someone not acquainted with the Christian mythology of the
 Crucifixion might consider a Crucifix to be a particularly sadistic
 piece of erotica... We of the ACLU will continue to defend your right to
 worship such objects if it pleases you." -- Gregory J. Wageman

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Mon, 4 Jul 1994 21:03:07 GMT
Organization: The Information Workshop

In article <2v6gua$[e-mail]> Alex Tang,
[e-mail] writes:

> Hi folks.  I've got some pretty newbie'ish questions about Gworlds...
>
> First, i haven't been able to find a good explaination about what
they're
> used for.  From the various bits of info that I've picked up, they
> comprise of a lot of different graphics devices and tools (i.e.
offscreen
> drawing).  Is that right?  Is the main purpose for them so that
offscreen
> drawing is easier?
>
> The main reason i'm asking is that I'm trying to write a small,
> rudamentary graphics app.  It's something to teach me how to do
> mac programming.  Basically, it's supposed be able to open some windows,
> do some drawing into the wndows, and save the file as a PICT.  I've hit
a
> minor roadblock trying to figure out how where to draw the stuff and be
> able to do updates on it.  At first, I thought I could draw directly to
> the window, but that didn't work.  I'm trying to figure out if i need to
> use gworlds for this (and i guess i should learn about them anyway).
>
> Well, Thanx for any insight that is provided.
>
> ...alex...


Alex,

Here is the answer to all of your questions at once.  It is the answer
you were looking for...

As an illustrative example, let's say your application has one window
which contains an XY bar graph of some data you have.  This graph would,
of course, have the XY lines, the tick marks, the numbers for the tick
marks, the titles, the data bars, etc, all made up of a series of
QuickDraw calls, such as MoveTo, LineTo, FrameRect, PaintRect,
DrawString, etc.


- --- Setting up your application

All "imaging" for this window should happen ONLY in response to the
"update" event that is sent to this window.  Period.  Your update event
handler should look something like this...

  void DoUpdateEvent( WindowPtr  theWindow )
  {
     BeginUpdate( theWindow );
     DrawWindowContents( theWindow );
     EndUpdate( theWindow );
  }

The routine "DrawWindowContents" should draw EVERYTHING that appears in
your window whenever it is called regardless.  This is the correct thing
to do.  A window should always start life this way.  Do NOT put any calls
to draw this window anywhere else in your software.  No exceptions.

When the window is created, an update event will automatically be sent to
it. Convenient.

And if there is some reason you need to update a certain area of your
window (and the system didn't ask you to), you can do this by
"invalidating" the desired area of your window, by calling InvalRect().
This triggers an update event to have that area of the window "cleaned
up".

In your update event handler, you must use the BeginUpdate and EndUpdate
calls, allowing you to take advantage of the Window Manager, which keeps
track of which part of your window actually needs to be re-drawn. ( The
update region ).

Your DrawWindowContents() routine will blindly draw everything to this
window, but the OS will automatically cut short any QuickDraw calls that
draw to areas of the window that do not actually need updating.

Even with this automatic built-in optimization, if you have a very
complex drawing, you will find that updating the window can be sluggish,
and you can see all the individual elements being re-drawn, as you do can
in, say, a complex MacDraw or Canvas drawing.

This is where GWorlds come in handy...


- --- Incremental Improvement #1

In response to the update event, create a GWorld the same size as your
window, draw the whole image into the GWorld instead, and then draw the
entire GWorld to the window all at once using CopyBits, then dispose of
the GWorld.

This makes it so the user does not see all the individual elements being
redrawn.

This is what happens when you do a "lock screen" then an "unlock screen"
in HyperCard.

This does not, however, eliminate the time it takes to draw all the
individual elements. If you were to, say, move another window that
overlaps the bar graph window by just one pixel, an update event would,
of course, be sent to your bar graph window, and it would spend the time
redrawing the scores of things that make up the image.  To help optimize
that, we can take the usage of our GWorld a step further...


- --- Incremental Improvement #2

When you create your window for the first time, also create a GWorld the
same size as your window, and have DrawWindowContents() draw its image
into the GWorld instead, once only, to "prep" the GWorld.

Then from that point on, in response to an update event, simply use
CopyBits to transfer the ENTIRE GWorld to the entire window.  The Window
Manager will only allow the needed areas to actually be transferred, and
you will now have the most efficient and optimal way of handling the
imaging of window contents.

Your window updating will now be instantaneous, and there will be no
sluggishness.

When you close the window, dispose of the GWorld too.


- --- Important Note

This explanation is a lot like putting you in a row boat and giving you a
starting push in the direction of that little reef offshore you want to
get to.

You do not need to know all about boats, all about the ocean, and all
about propulsion in order to make it to that little reef successfully.
You also do not need to know at this time how to handle things
differently if you were hypothetically put in an outrigger instead.

Don't allow yourself or others to unnecessarily complicate things.  Take
this simple push and go with it, and you will quickly "get it".


- --- Following Advice

Mark my words.  If you put drawing-to-window code anywhere else than in
your update handler, you will find that a good chunk of your code, and
the time it took to develop it, ends up being spent on compensating for
the problems and side-effects that were created as a result of not
following this sage advice.

I made this mistake myself when I first started, and paid a hefty price
for it, too.  Hopefully you can avoid the waste of repeating this common
(and undocumented) programming error.


Hope this helps!

Mark Hanrek
The Information Workshop


- ----------------------------------

P.S.  The other undocumented programming error waiting to eat you is
mixing the use of GetPort/SetPort and GetGWorld/SetGWorld in the same
application.

The minute you start working with GWorlds, eliminate all uses of
GetPort/SetPort from your application, changing them all to the more
modern GetGWorld/SetGWorld.

Ouch!

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Tue, 5 Jul 1994 17:04:15 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

For more reading on GWorlds, get "Programming QuickDraw" by Surovell,
Hall and Othmer.

For an example of an application comparison WITHOUT and WITH GWorlds
(GWorld added by Mark Hanrek) get NuCube and NewCube C source demos. (I
believe they are on sumex, in a file called "ThreePointPlotters" or
"WireFrameORama").

There are excellent, comprehenhive examples of GWorld C sources on
ftp.apple.com (GWorld Drawing - not an app. source, but several routines)
and "GWorlds" from devtools.symantec.com - source for a complete application.

Of course, there are many more, too.  cicnAnimDemo uses GWorlds.

I was told, by a downloader of NuCude (which Mark contributed to), that
he really gained a lot of understanding of them from the source.  Well,
Mark understands them - that's why.

-Ken-

---------------------------

>From [e-mail] (Dave Brewster)
Subject: Patching Trap ExitToShell using UniversalProcPtr's
Date: 5 Jul 1994 01:38:45 -0400
Organization: Eisenhower National Clearinghouse

How does one go about doing this on the PPC.  I've tried:
   SetToolTrapAddress(MyExitToShellUPP, _ExitToShell);
where MyExitToShellUPP =
   NewRoutineDescriptor((ProcPtr)(MyExitToShell), kCStackBased,
GetCurrentISA());

I figured this would be correct, but it dies a violent death!

Is the kCStackBased parameter wrong?  My routine doesn't take any
parameters so I'm not or'ing this with anything.  Oh yea, and it doesn't
return anything either.

My ExitToShell routine looks like:

void MyExitToShell (void)
{
   SetCurrentA5();
   SetToolTrapAddress(gOldExitToShellTrapAddress, _ExitToShell);
   EndNNTP();
   NetTerm();
   ExitToShell();
}

What's the deal,

Dave

+++++++++++++++++++++++++++

>From [e-mail] (Stephen F Coy)
Date: 5 Jul 1994 13:52:33 GMT
Organization: Microplex Pty Ltd

Dave Brewster ([e-mail]) wrote:
: How does one go about doing this on the PPC.  I've tried:
:    SetToolTrapAddress(MyExitToShellUPP, _ExitToShell);
: where MyExitToShellUPP =
:    NewRoutineDescriptor((ProcPtr)(MyExitToShell), kCStackBased,
: GetCurrentISA());

: I figured this would be correct, but it dies a violent death!

: Is the kCStackBased parameter wrong?  My routine doesn't take any
: parameters so I'm not or'ing this with anything.  Oh yea, and it doesn't
: return anything either.

: My ExitToShell routine looks like:

: void MyExitToShell (void)
: {
:    SetCurrentA5();
:    SetToolTrapAddress(gOldExitToShellTrapAddress, _ExitToShell);
:    EndNNTP();
:    NetTerm();
:    ExitToShell();
: }

If you use the standard C library function "atexit" instead you would not
have to worry about all this stuff.

In general, you should avoid patching traps. Most of the time it is
not necessary.


 : What's the deal,

: Dave

Steve Coy
Resolve Software (WA) P/L


+++++++++++++++++++++++++++

>From [e-mail] (Bill Hofmann)
Date: Tue, 5 Jul 1994 16:11:42 GMT
Organization: Fresh Software

In article <[e-mail]>,
[e-mail] (Dave Brewster) wrote:

> How does one go about doing this on the PPC.  I've tried:
>    SetToolTrapAddress(MyExitToShellUPP, _ExitToShell);
> where MyExitToShellUPP =
>    NewRoutineDescriptor((ProcPtr)(MyExitToShell), kCStackBased,
> GetCurrentISA());
>
> I figured this would be correct, but it dies a violent death!
>
> Is the kCStackBased parameter wrong?  My routine doesn't take any
> parameters so I'm not or'ing this with anything.  Oh yea, and it doesn't
> return anything either.
>
> My ExitToShell routine looks like:
>
> void MyExitToShell (void)
> {
>    SetCurrentA5();
>    SetToolTrapAddress(gOldExitToShellTrapAddress, _ExitToShell);
>    EndNNTP();
>    NetTerm();
>    ExitToShell();
> }
Well, with few exceptions, the entire toolbox is either kPascalStackBased
or kRegisterBased.  So you have two (well, 1.5) problems:

MyExitToShellUPP = NewRoutineDescriptor((ProcPtr)MyExitToShell,
                        kPascalStackBased, GetCurrentISA());
...
pascal void MyExitToShell(void)
{
...
}

I say 1.5 because a pascal void ... (void) is pretty much the same as a
void ... (void), but better to be compulsive than sorry.  I assume that
you init gOldExitToShellTrapAddress.  Does your code (minus the
NewRoutineDescriptor()) work on 040 machines?

--
Bill Hofmann                                   [e-mail]
Fresh Software and Instructional Design        voice: [phone]
1640 San Pablo Ave #C, Berkeley CA 94702 USA   fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Bell)
Date: Tue, 05 Jul 1994 18:34:35 -0600
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Dave Brewster) wrote:

> How does one go about doing this on the PPC.  I've tried:
>    SetToolTrapAddress(MyExitToShellUPP, _ExitToShell);
> where MyExitToShellUPP =
>    NewRoutineDescriptor((ProcPtr)(MyExitToShell), kCStackBased,
> GetCurrentISA());
>
> I figured this would be correct, but it dies a violent death!
>
> Is the kCStackBased parameter wrong?  My routine doesn't take any
> parameters so I'm not or'ing this with anything.  Oh yea, and it doesn't
> return anything either.
>
> My ExitToShell routine looks like:
>
> void MyExitToShell (void)
> {
>    SetCurrentA5();
>    SetToolTrapAddress(gOldExitToShellTrapAddress, _ExitToShell);
>    EndNNTP();
>    NetTerm();
>    ExitToShell();
> }
>
> What's the deal,
>
> Dave

Here's the code I used to do the same thing

// KMB: ExitToShell UPP Info

static UniversalProcPtr gOldExitToShellTrapAddress;

enum {
    exitToShellProcInfo = kPascalStackBased
};

static void PatchExitToShell (void)
{
    UniversalProcPtr MyExitToShellUPP =
        NewRoutineDescriptor((ProcPtr)MyExitToShell,
                         exitToShellProcInfo,
                         GetCurrentISA());
    gOldExitToShellTrapAddress = GetToolTrapAddress(_ExitToShell);
    SetToolTrapAddress(MyExitToShellUPP, _ExitToShell);
}


    BTW, thanks for asking this question. When I tried to open the source
code with my PowerMac compiled NewsWatcher, I discovered some errors with
my standard file UPP stuff. IMHO, universal procedure pointers have a
serious problem in that the compiler cannot do any type checking like it
could for regular function pointers. In my case, I was creating a
FileFilterUPP where a ModalFilterUPP was needed.

--
Kevin Bell
[e-mail]

---------------------------

>From [e-mail] (Gordan Todorovac)
Subject: Porting from Unix to Mac - Summary
Date: 1 Jul 1994 17:29:34 GMT
Organization: Haverford College Computer Science Department

Thanks to all who replied. Here is the content of three replies which summarize
what was said:


>From [e-mail] Fri Jul  1 07:22:10 1994

  I haven't used version 5 for a year or more, but I'm quite sure that
malloc was available...#include <stdlib.h> and add the ANSI library to
your project certainly works in v6 and its not something new I've added
during the upgrade.

  If you're looking to move away from Unix-isms, there are Toolbox
calls, NewPtr and DisposPtr, for memory management.

  (I've done a few small ports of things that started on Unix.  My major
problems have been trying to understand library calls that don't exist
and don't seem to have matching concepts on the Mac...fork?
yfork?...but most of them should be there.)


>From [e-mail] Fri Jul  1 10:32:54 1994

I port code from the Unix to the Mac and from the Mac to Unix all the time
(and to the PC in between).  The main thing to keep in mind is *not* to use
UNIXisms or MACisms (or PCisms).  If you program in strictly ANSI C, you
will
not have a problem going either direction.  Now that does eliminate taking
advantage of platform specific features.  But thats actually what
portability
is all about.

As for malloc, include stdlib.h for the prototype and add ANSI to your
project and you are all set.  Note:  THINK C gives you a set of unix-like
functions
in unix.h that help you compile *some* code containing some UNIXisms.
However,
most do not implement the semantics/behavior of the unix function (mostly
because they have no MAC equivalent).  I would not use them except as a
last
resort.


>From [e-mail] Fri Jul  1 11:27:52 1994

One of the biggest differences between Mac and Unix systems is the way the
operating system allocates memory. Unix uses pointers, Macs use handles,
which are pointers to pointers. The malloc function tells the Unix system to
allocate a certain amount of memory and returns a pointer to it. Macs use a
function called NewHandle to allocate a block of memory, and a handle is
returned.

There is a Mac function called NewPtr (in the memory.h file, I believe),
which allocates a block of memory and returns a pointer to it. Allocating
memory on a Mac with pointers, however, can be a bad idea because memory
segmentation can occur, especially if you are allocating a lot of memory.
You could replace all of the mallocs in your code with NewPtr, if you're not
worried about memory segmentation. This has the advantage of you not having
to make changes to your code in the parts where pointers are referenced. If
you use NewHandle to replace malloc, however, you will have to go and find
all of the places where pointers are referenced and make some changes.

Another area of difference between Unix and Macs are in the functions which
are used to handle files. You can expect problems in this area if your Unix
program reads or writes files.

- -------------------------------
--Gordan


---------------------------

>From [e-mail] (Rick Watson)
Subject: Problems with Metrowerks vs. MPW 68k C calling conventions
Date: 29 Jun 1994 18:43:25 GMT
Organization: The University of Texas at Austin, Austin, Texas

Metrowerks 68k C passes short values on the stack as 16-bit
values where MPW uses 32 bits. This causes problems when trying
to call MPW generated code modules, including MacTCP's
domain resolver code called by DNR.c.

Is there an easy workaround for this that does NOT involve prototyping
the short values as longs?

Rick Watson
The University of Texas Computation Center, Networking Services, 512/471-8220
 [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ed Allen and Avi Rappoport)
Date: 29 Jun 1994 22:47:27 GMT
Organization: The Whole Earth 'Lectronic Link, Sausalito, CA

[e-mail] (Rick Watson) writes:

>Metrowerks 68k C passes short values on the stack as 16-bit
>values where MPW uses 32 bits. This causes problems when trying
>to call MPW generated code modules, including MacTCP's
>domain resolver code called by DNR.c.

>Is there an easy workaround for this that does NOT involve prototyping
>the short values as longs?

Nope, there is no easy workaround.  Pascal libraries are fine, but C
libraries have different parameter passing conventions, as you note
above.  If you can get the source, compile it in MW.

Sorry.

--
Avi Rappoport                         (account also used by Ed Allen)
Systems Analyst and Technical Diplomat
metrowerks, Inc.
Please reply to: [e-mail]  [e-mail]  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (MW Ron)
Date: 29 Jun 1994 17:35:04 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <2usfcd$[e-mail]>,
[e-mail] (Rick Watson) writes:

>>Metrowerks 68k C passes short values on the stack as 16-bit
values where MPW uses 32 bits.
Is there an easy workaround for this that does NOT involve
prototyping
the short values as longs?

Did you change the structure allignment in your preferences Processor
for 4 byte int and 8 byte doubles,  and use the proper Libraries? I
am not an MPW user so if this isn't the fix, please reply.

Ron Liechty
[e-mail]
Metrowerks Inc.


+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Thu, 30 Jun 1994 05:42:45 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Rick Watson) writes:

>Metrowerks 68k C passes short values on the stack as 16-bit
>values where MPW uses 32 bits. This causes problems when trying
>to call MPW generated code modules, including MacTCP's
>domain resolver code called by DNR.c.

The problem is that although you may declare an argument 'short' or
'char' in MPW C, it will pass it as 32-bits. This was common in K&R
compilers but is rare in ANSI compilers (THINK C does it the same way
that we do)

The trick is to fool CW by declaring all integer arguments as 'long' in
the prototype (including enums). Then the arguments will be properly
extended to 32-bits.

-- John McEnerney, Metrowerks PowerPC Product Architect


+++++++++++++++++++++++++++

>From [e-mail] (Charlie Reiman)
Date: Fri, 1 Jul 1994 05:36:05 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (MW Ron) writes:

>In article <2usfcd$[e-mail]>,
>[e-mail] (Rick Watson) writes:

>>>Metrowerks 68k C passes short values on the stack as 16-bit
>values where MPW uses 32 bits.
>Is there an easy workaround for this that does NOT involve
>prototyping
>the short values as longs?

>Did you change the structure allignment in your preferences Processor
>for 4 byte int and 8 byte doubles,  and use the proper Libraries? I
>am not an MPW user so if this isn't the fix, please reply.

>Ron Liechty
>[e-mail]
>Metrowerks Inc.

Think C has the exact same feature, even with 4 byte ints turned on.  I
did call up Symantec tech support and argue about this. I can no longer
quote the K&R ANSI page number, but the behavior you are seeing is not
incorrect.

It's stupid, but not incorrect.

You need prototypes under Think, MW may have another solution.

--
"You can't cancel the project! We already made the T-shirts!"
Charlie Reiman
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Steven Ellis)
Date: Thu, 30 Jun 1994 10:50:06 GMT
Organization: MicroAPL


In article <2usfcd$[e-mail]> [e-mail] (Rick
Watson) writes:
>Metrowerks 68k C passes short values on the stack as 16-bit
>values where MPW uses 32 bits. This causes problems when trying
>to call MPW generated code modules, including MacTCP's
>domain resolver code called by DNR.c.
>
>Is there an easy workaround for this that does NOT involve prototyping
>the short values as longs?

If you look in the compiler preferences there is an option to use 4byte short
values.

>
>Rick Watson
>The University of Texas Computation Center, Networking Services, 512/471-8220
> [e-mail]
>

Steven Ellis

+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Fri, 1 Jul 1994 15:23:53 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Charlie Reiman) writes:

>>>>Metrowerks 68k C passes short values on the stack as 16-bit
>>values where MPW uses 32 bits.
>>Is there an easy workaround for this that does NOT involve
>>prototyping
>>the short values as longs?

>Think C has the exact same feature, even with 4 byte ints turned on.  I
>did call up Symantec tech support and argue about this. I can no longer
>quote the K&R ANSI page number, but the behavior you are seeing is not
>incorrect.
>It's stupid, but not incorrect.

Everybody thinks that they're a compiler designer...

The ANSI standard clarified that when an argument is declared 'float',
'char' or 'short' it does not have to be widened to 'double' or 'int'
when passed as an argument. (The only exception is when there is no
prototype or for arguments matching the "...") It also clarified that a
compiler is not required to pass arguments in reverse order when the
number of arguments in known.

This permits ANSI compilers to generate much better code, in this case
avoiding an EXT.W for each argument passed. Some compilers (including
Symantec C++ I think) will pass arguments in the order that they are
declared and will have the calleee strip the arguments, again contrary to
K&R practice, but also usually more efficient.

I don't see why every compiler for the Mac has to be saddled with the
calling conventions of a compiler that Apple hasn't done any work on in 5
years.

-- John McEnerney, Metrowerks PowerPC Product Architect

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Fri, 1 Jul 1994 18:36:29 GMT
Organization: Apple Computer

Steven Ellis, [e-mail] writes:
> If you look in the compiler preferences there is an option to use 4byte
short
> values.

No, there is an option to use 4byte ints. shorts are always two bytes on
every Mac compiler (and on just about every other C compiler in the world,
with a few exceptions.) And shorts will always be pushed as 2 bytes by every
Mac compiler except MPW C.

I understand that Apple, Symantec and Metrowerks are hammering out a standard
C calling convention to be used by all their compilers, at least optionally
via pragmas. This becomes important with CFM and SOM on 68k, where C calling
conventions are used. (On PPC of course there is already one standard set of
calling conventions.)

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Charlie Reiman)
Date: Sat, 2 Jul 1994 00:43:50 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (John McEnerney) writes:

>[e-mail] (Charlie Reiman) writes:

>>>>>Metrowerks 68k C passes short values on the stack as 16-bit
>>>values where MPW uses 32 bits.
>>>Is there an easy workaround for this that does NOT involve
>>>prototyping
>>>the short values as longs?

>>Think C has the exact same feature, even with 4 byte ints turned on.  I
>>did call up Symantec tech support and argue about this. I can no longer
>>quote the K&R ANSI page number, but the behavior you are seeing is not
>>incorrect.
>>It's stupid, but not incorrect.

>Everybody thinks that they're a compiler designer...

>The ANSI standard clarified that when an argument is declared 'float',
>'char' or 'short' it does not have to be widened to 'double' or 'int'
>when passed as an argument. (The only exception is when there is no
>prototype or for arguments matching the "...") It also clarified that a
>compiler is not required to pass arguments in reverse order when the
>number of arguments in known.

>This permits ANSI compilers to generate much better code, in this case
>avoiding an EXT.W for each argument passed. Some compilers (including
>Symantec C++ I think) will pass arguments in the order that they are
>declared and will have the calleee strip the arguments, again contrary to
>K&R practice, but also usually more efficient.

>I don't see why every compiler for the Mac has to be saddled with the
>calling conventions of a compiler that Apple hasn't done any work on in 5
>years.

Don't get me wrong. I understand what you are trying to do. I just
think the anguish it causes developers isn't worth the win in compiler
speed. Calling it 'stupid' may have been harsh but you weren't here
when I had to debug the problem it caused. Nor were you here when I had
to wedgie protoypes on top of 300,000+ lines of complex cross-platform
code to avoid future problems.

I may not be a compiler designer, but I sure do beat the crap out of
them.  I know what breaks and I simply have to disagree with you.

--
"You can't cancel the project! We already made the T-shirts!"
Charlie Reiman
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lars Farm)
Date: Sat, 02 Jul 1994 11:56:40 +0100
Organization: Mid Sweden University

In article <[e-mail]>, Jens Alfke
<[e-mail]> wrote:

> I understand that Apple, Symantec and Metrowerks are hammering out a standard
> C calling convention to be used by all their compilers, at least optionally
> via pragmas. This becomes important with CFM and SOM on 68k, where C calling
> conventions are used. (On PPC of course there is already one standard set of
> calling conventions.)

Isn't this a place for extern "OtherCallingConvention" void foo(int);
as in extern "C", or extern "MPW", or extern "ASLM", or extern "SOM", or
extern "CFM", or extern "Pascal", ... leaving internal calling conventions
as an implementation detail to the specific compiler vendor?

Instead of #pragmas or worse - project wide preferences.

Lars

--
[e-mail]

---------------------------

>From [e-mail] (  Mr. Neb)
Subject: Special #define for Univ. Hdrs?
Date: 3 Jul 1994 04:16:21 GMT
Organization: Bowling Green State University

  Here's a quicky: I just got done adding Univ. Hdrs. to TC7.0.3
(headers from develop 18 CD) and started to recompile some existing
code to see if it would fly without any serious modifications.

  Everything was going fine until I recompiled a project that was using
IconFamilies.h (for those of you who don't remember, IconFamilies.h
was the file defined in TechNote #306, "Drawing Icons the System 7
Way").  Everything from IconFamilies.h has been shuffled into Icons.h.

  Hey, that's fine with me.  But I would like to modify my source to
include IconFamilies.h if the univ. hdrs. are not available.  Easiest
way to do this, I says to myself, is to surround the #include with
an #ifndef.  The only problem is that I don't know if there is a
constant defined so that I can distinguish between the old headers
and the universal headers.

  So to wrap up, is there a constant defined somewhere within the
universal headers?

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>

             *THE* alt.sources.mac supporter!


+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 4 Jul 94 14:31:12 GMT
Organization: PowerTools, Austin, Texas

In article <2v5e2l$[e-mail]> [e-mail] (  Mr. Neb) writes:

>  So to wrap up, is there a constant defined somewhere within the
>universal headers?

I've been using #ifdef __CONDITIONALMACROS__. As far as I can tell,
<ConditionalMacros.h> gets included any time you're using the
universal headers, but doesn't exist if you're not.

                    --Al Evans--
--
Al Evans            |   Graphic Elements: A new standard for
                |   high-performance interactive Macintosh graphics.
[e-mail]  |   Available from mac.archive.umich.edu
                |   /mac/misc/demo/graphicelementsdemo.sit.hqx

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Mon, 04 Jul 1994 10:32:51 +0800
Organization: NCRPDA, Curtin University

In article <2v5e2l$[e-mail]>, [e-mail] (  Mr. Neb) wrote:

>  Hey, that's fine with me.  But I would like to modify my source to
>include IconFamilies.h if the univ. hdrs. are not available.  Easiest
>way to do this, I says to myself, is to surround the #include with
>an #ifndef.  The only problem is that I don't know if there is a
>constant defined so that I can distinguish between the old headers
>and the universal headers.

Wow, another few years and this will be almost as much fun as trying to
get a unix program compiled.

I just love the C #define, #include method of seperate compilation.
Brilian piece of design :-)
   Peter.
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

---------------------------

>From [e-mail] (Mark D. Taylor)
Subject: Why does THINK C use a jump table?
Date: 17 Jun 1994 10:08:53 -0700
Organization: Apple Computer Inc, Cupertino, CA

Or more specifically, why does a call of a function in the same source file
and segment of the caller go through a jump table?

I'm having a problem with this because the call occurs at interrupt time
when A5 is not guaranteed and sometimes the jump table is not where the code
thinks it should be.

So what controls whether the jump table is used?  How can I disable it?

Thanks,
Mark


+++++++++++++++++++++++++++

>From [e-mail] (eric doc kampman)
Date: Fri, 17 Jun 1994 18:17:52 -0800
Organization: farallon

In article <2tslb5$[e-mail]>, [e-mail] (Mark D. Taylor)
wrote:

> Or more specifically, why does a call of a function in the same source file
> and segment of the caller go through a jump table?
>
> I'm having a problem with this because the call occurs at interrupt time
> when A5 is not guaranteed and sometimes the jump table is not where the code
> thinks it should be.
>
> So what controls whether the jump table is used?  How can I disable it?

Short answer -- as far as I can tell, when one routine calls another it
*always* goes through the jump table -- even if the routine you're calling
is defined in the same source file and is 2 bytes away from the PC.  This
"feature" has caused me to retreat back to MPW when I'm not doing OOP
stuff.  You're going to have to save your A5 somewhere you can retrieve it
when you're not the front app.  There are many different situations where
this occurs and many ways of handling it.  For a generic solution -- check
out <SetUpA4.h> (in THINK #includes) for a *very* interesting way of saving
register values where you can get to them. It takes a little while to see
why what they're doing works (or at least it did for me).

--
[e-mail]
Farallon didn't write this, Farallon isn't responsible for its con-
tents -- Farallon is an abstract class and cannot be held responsible
for the quality of instantiations of derived classes.
********************************************************************
 Look for the thing you can't find/Seeing with eyes makes you blind
               You know you're out of your mind

+++++++++++++++++++++++++++

>From [e-mail] (Rich Siegel)
Date: Sat, 18 Jun 1994 01:20:21 GMT
Organization: Bare Bones Software

In article <2tslb5$[e-mail]> [e-mail] (Mark D. Taylor) writes:
>Or more specifically, why does a call of a function in the same source file
>and segment of the caller go through a jump table?

(one of) Two reasons: it's not declared 'static', and/or you take its
address at some point in the code. If it's not declared static, it
needs to be accessible through the jump table so that other functions
can call it. If you take its address, it has to be indirected thruogh
the jump table to ensure position independence.

R.



--
Rich Siegel % [e-mail]    % Principal, Bare Bones Software
--> For information about BBEdit, finger [e-mail] <--

"...yeah, I inhaled, and then I drank the bong water. So what're
you gonna do about it?" - Dennis Miller, on Bill Clinton

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Sat, 18 Jun 1994 05:00:40 GMT
Organization: cellular

[e-mail] (Mark D. Taylor) writes:

>Or more specifically, why does a call of a function in the same source
>file and segment of the caller go through a jump table? I'm having a
>problem with this because the call occurs at interrupt time when A5
>is not guaranteed and sometimes the jump table is not where the code
>thinks it should be. So what controls whether the jump table is used?
>How can I disable it?

You can't disable it without using another compiler, but you can make
sure your interrupt code works. First make sure the segment in question
is loaded by doing some work at non-interrupt time. Make a call into
the segment, perhaps to a dummy routine which exists solely to force
the segment to load. Make sure you don't subsequently call UnloadSeg
for that segment. Then, in your interrupt code, make sure A5 is set up
properly before you make the interrupt-time call into the segment. I
believe you will find relevant documentation in the usual places under
'SetCurrentA5'.

None of this stuff is relevant under PowerPC, of course.
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

 'It seems the firm contracted by Intel to produce the famed "flying
 Pentium" ads could not complete the 3-D modeling on a PC before
 deadline. So in the best know-your-enemy tradition, they chose the next
 best thing -- a Quadra 840AV.'                 -- Mac The Knife 4/18/94

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Sat, 18 Jun 1994 17:26:11 GMT
Organization: cellular

[e-mail] (Mark D. Taylor) writes:

>Or more specifically, why does a call of a function in the same source
>file and segment of the caller go through a jump table?

Rich posted the reasons why, and I posted a way for you to make your
interrupt code work. But I don't think anybody yet has specifically
talked about the general case of how to make jump table entries go away.
If your routine is declared 'static' and you don't take its address,
*that* will guarantee it will not generate a jump table entry. (If your
routine is only referenced from its own segment, it will not generate a
jump table entry when building a stand-alone app, but it's more common
for programmers to want to run their app from TPM.)

This gives me an opportunity to be even a little more pedantic.

THINK C supports a language extension "require prototypes". Most people
should have it turned on (in the project settings dialog), because it
only helps you build safer and stronger software at the expense of some
extra typing sometimes. But most people don't know how to take advantage
of it. They turn it on, and the compiler encounters a function like
'foo':

    void foo (void) { }
    void main (void) { foo ( ); }

...and of course the compiler complains because there is no prototype
for 'foo' in scope. People's response is generally to give the compiler
a prototype, even for routines which will never be called from another
module:

    void foo (void);
        void foo (void) { }
        void main (void) { foo ( ); }

...and this makes the compiler shut up. But there is a much better way:

    static void foo (void) { }
        void main (void) { foo ( ); }

...this not only makes the compiler shut up, but it prevents 'foo'
from requiring a jump table entry, as long as you don't also take its
address. This not only keeps your jump-table less crowded, but it also
relieves you of having to deal with the possibility that A5 (or A4 in
some cases) is not valid when 'foo' is called. (If 'foo' is going to
call other routines which rely on A5 (or A4), 'foo' still needs to make
sure A5 (or A4) is valied before calling those other routines.)

Now, some people will say that relying on this behavior is a bad idea,
because the ANSI standard doesn't specify that 'static' should have
this effect. However, neither does the ANSI standard specify that a
feature like "require prototypes" be supported. When you hit the "ANSI
settings" button in the prefs dialog, notice that "infer prototypes"
gets selected, not "require prototypes". So since "require prototypes"
isn't ANSI in the first place, you might as well rely on the 'static'
keyword to help you use "require prototypes". I know CodeWarrior
supports it, by the way, and I suspect MPW C supports it in some similar
fashion, as well.

The reason I really like to use the 'static' keyword in this way is the
way THINK C segmentation works. You can only control segmentation at the
module level, so by definition 'static' routines cannot be called from
another segment. The linker simply won't cooperate. Using the 'static'
keyword in this way can prevent a whole layer of mistakes before they
require debugging time.
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

 You thought Obfuscated C was confusing? Wait for Obfuscated C++!

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Mon, 20 Jun 1994 04:47:12 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Pete Gontier <[e-mail]> wrote:
>...
>The reason I really like to use the 'static' keyword in this way is the
>way THINK C segmentation works. You can only control segmentation at the
>module level, so by definition 'static' routines cannot be called from
>another segment. The linker simply won't cooperate. Using the 'static'
>keyword in this way can prevent a whole layer of mistakes before they
>require debugging time.

There's another good reason to use this feature. It saves you from
having to put prototypes into the file, which means a bit less work
for the programmer/maintainer. It also helps give some logical
structure to your source files, since static functions need to be
defined before you can use them. If you really need to use a function
before it's defined, you can place a prototype for that function near
the head of the source file.
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From Aaron Wohl <[e-mail]>
Date: Fri,  1 Jul 1994 09:12:14 -0400
Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA

There are two ways around think c using A5 to make calls:

a) have an lea instruction at the start of the routine (use asm {}) and
patch it before using the address at interrupt time.  (then flush the
code caches)

b) Compile the code in question as a code resource and load the resource.

See the code samples on akutaktak.andrew.cmu.edu [128.2.35.1] in the
/aw0g directory for some examples of using code resources.


---------------------------

End of C.S.M.P. Digest
**********************